Summary

Fixes Failed to open blob file: no such file or directory errors during NZBDav import scans, where the scan reports total_files: 0 even though the blobs directory is accessible.

Root cause

nzbdav's C# BlobStore writes blob files using Guid.ToString("N") and Guid.ToString(), both of which always emit lowercase hex:

var guidStr = id.ToString("N");     // "0aa2bd24b90c4e06a301dd0d296ad86c"
var firstTwo = guidStr[..2];        // "0a"
var nextTwo  = guidStr.Substring(2, 2); // "a2"
var fileName = id.ToString();       // "0aa2bd24-b90c-4e06-a301-dd0d296ad86c"
// Path: blobs/0a/a2/0aa2bd24-b90c-4e06-a301-dd0d296ad86c

But EF Core stores the NzbBlobId column as uppercase hyphenated text (e.g. 0AA2BD24-B90C-4E06-A301-DD0D296AD86C). altmount was passing that DB value directly into filepath.Join, so on case-sensitive filesystems (Linux ext4, etc.) every os.Open failed, and since count++ only runs on success, the final log showed total_files: 0.

Change

Normalize the blob ID to lowercase before constructing the filesystem path in internal/nzbdav/parser.go. Also add TestParser_Parse_Blobs_UppercaseUUID as a regression test that stores an uppercase UUID in the DB and the lowercase file on disk — the existing tests used 16-char lowercase hex fixtures so they never tripped this bug.

Test plan

• go test -race ./internal/nzbdav/... — new test passes, existing tests stay green
• Re-run an NZBDav import scan against a real /blobs directory and confirm no Failed to open blob file errors and a non-zero total_files